Date: Thu, 14 Jul 94 04:30:07 PDT From: Advanced Amateur Radio Networking Group Errors-To: TCP-Group-Errors@UCSD.Edu Reply-To: TCP-Group@UCSD.Edu Precedence: Bulk Subject: TCP-Group Digest V94 #148 To: tcp-group-digest TCP-Group Digest Thu, 14 Jul 94 Volume 94 : Issue 148 Today's Topics: ARRL DIG COMM CONF. NEWS Rev 7/12/94 ARRL DIGITAL COMM CONF UPDATE BULLETIN 7/12/94 Bridge vs. Repeater Managing MSS and Window; IP encapsulation (3 msgs) Send Replies or notes for publication to: . Subscription requests to . Problems you can't solve otherwise to brian@ucsd.edu. Archives of past issues of the TCP-Group Digest are available (by FTP only) from UCSD.Edu in directory "mailarchives". We trust that readers are intelligent enough to realize that all text herein consists of personal comments and does not represent the official policies or positions of any party. Your mileage may vary. So there. ---------------------------------------------------------------------- Date: Wed, 13 Jul 94 21:03:11 CST From: edf@bbs.wd0hxt.ampr.org Subject: ARRL DIG COMM CONF. NEWS Rev 7/12/94 To: tcp-group@UCSD.EDU ----- Forwarded message ----- When you think about it, unless you've got a clear freq of your own and don't have to share it with lots of other packet stations, a beam is discourtious UNLESS (!) it is also cophased with an omni. Why? Beacuse the beam's back-door rejection will allow your station to keyup on top of other stations, resulting not only in increased band congestion but also avoidable interference that could lead to disconnections. It's easy to cophase an omni to a beam. Just run a 1/4 wavelength of 75 ohm coax to each 50 ohm antenna and to the transmitter 50 ohm line. Yes, beam (and omni) power output is 1/2 of what you get if just one antenna were online, but a good beam will make up for that and the omni will let you hear stations instead of keying up on top of them. Just some Month of May Thoughts ... :) 73 de Ron KC6RCO@KC6RCO.#ECMN.MN.USA.NA Internet: ronm@kc6rco-nrom.ampr.org ----- End of forwarded message ----- ------------------------------------------------------------------------------- de Ed Fairbairn WD0HXT internet/amprnet = edf@bbs.wd0hxt.ampr.org pbbsnet = wd0hxt@wd0hxt.#msp.mn.usa.na ------------------------------ Date: Wed, 13 Jul 94 21:13:38 CST From: tcp-info@bbs.wd0hxt.ampr.org Subject: ARRL DIGITAL COMM CONF UPDATE BULLETIN 7/12/94 To: tcp-group@UCSD.EDU ----- Forwarded message ----- ARRL 13th ANNUAL DIGITAL COMMUNICATIONS CONFERENCE AUGUST 19-21 Do you operate a Digital mode (maybe Pactor, Packet, GTOR or AMTOR) now? Do you find it difficult to keep up with the latest Digital technology? Would you like to know more about Digital modes? If you answered "yes" to any of these questions, then you should attend the 13th Annual ARRL Digital Communications Conference. Read on ... The Conference will be held on August 19 - 21, 1994 at the Thunderbird Convention Center, 2201 East 78th Street in Bloomington, Minnesota. Accomodations are available at the adjacent Thunderbird Hotel, at the many Hotels and Motels located within a short distance, and also at several area RV\camper campgrounds. Enjoy a weekend of fun learning about the latest developments in TCP/IP, PACTOR, AMTOR, PACTOR-II, CLOVER, G-TOR, PACKET, DSP, and imaging. Participate in the nine forums about DSP, new HF modes, TCP/IP, VHF/UHF networking, BBS SYSOP issues and more. A glance at the program (attached) will show many forums that will catch your interest! One of the highlights of the conference will be the presentation of 18 technical papers on the many aspects of digital communications throughout the day on Saturday. A list of papers is attached. You will receive a copy of all papers presented. Many demonstrations of the latest in hardware and software will be presented. When you leave, you will have an in-depth understanding of the latest digital communications advancements and techniques. The Saturday evening Technical Showcase will feature TAPR Special Interest Group meetings for BBS SYSOPs and on VHF/UHF network building and a nearly-mathless presentation of the design and implementation of DSP software for a high-performance HF DSP modem based on the $99 TI DSK DSP evaluation module by Johan Forrer, KC7WW. The Hospitality Room will provide the place to meet old friends ... and make new ones. At the Saturday luncheon you will get to know "who's who" in digital communications. Meet the Engineering staff of manufacturers like Kantronics and Timewave Technologies. The optional Saturday evening diner will provide another opportunity to make new friends. If you want a break from the Conference, the Mall of America, with hundreds of unique stores, is located within easy walking distance. Your family will enjoy Knott's Camp Snoopy theme park inside the Mall. The renowned Minnesota Zoo is only a short drive away. The Conference registration fee is $45 per person, which includes admission to all Conference activities, a luncheon buffet and a copy of the technical papers. An optional Saturday evening buffet is $20 per person additional. Registration deadline is August 12th. For more information about the Conference or special Airline and Motel discounts call or write: ARRL Digital Communications Conference C/O Paul Ramey WG0G 16266 Finland Avenue Rosemount, MN 55068 Packet: WG0G@WA0CQG.#MSP.MN.USA.NA Telephone: (612) 432-1640 Internet: PRAMEY@RAM.NET The host organization for the 1994 ARRL Digital Communications Conference is the TwinsLAN Amateur Radio Club. See YOU at the Digital Communications Conference August 19-21! ------------------------------------------------------------------------------ 13th ANNUAL ARRL DIGITAL COMMUNICATIONS CONFERENCE PRELIMINARY PROGRAM Friday, August 19 TIME ROOM EVENT Noon - 6 PM TBD ARRL "Future Modes" Committee meeting. Noon - 6 PM TBD ARRL "219-MHz" Committee meeting. 4 - 10 PM Menominee Conference check-in. 6 PM - 11 PM Menominee Hospitality & Demo area open Saturday, August 20 TIME ROOM EVENT 6:30 - Noon Menominee Hospitality & Demo area open 7:00 - Noon Menominee Conference Check-in. 8:00 - 8:15 AM Miami Conference "Welcome" 8:30 - 10:00 AM Miami Technical Paper Presentation 8:30 - 10:00 AM Yakima Forum - Developments in DSP For the Amateur. 8:30 - 10:00 AM Shoshone Forum - TCP/IP - What's next? 10:00 - 10:15 AM All Break 10:15 - 11:45 AM Miami Technical Paper Presentation 10:15 - 11:45 AM Yakima Forum - ARRL Committee Updates: "Future Modes": Moderator - Paul Rinaldo W4RI and "219-MHz Networking": Moderator - Tod Olson K0TO" 10:15 - 11:45 AM Shoshone Forum - Digital Data (Voice and Image) Transmission Method Developments. 11:45 - Noon AM All Break Noon - 1:00 PM Miami Buffet Luncheon (Included) 1:00 - 5:30 PM Menominee Hospitality & Demo area open 1:15 - 2:45 PM Miami Technical Paper Presentation 1:15 - 2:45 PM Yakima Forum - High-Speed (above 1200 baud) data transfer methods and networking techniques. 1:15 - 2:45 PM Shoshone Forum - HF Data Transmission Methods - An Over-view of Current Modes and What's Coming Next. 2:45 - 3:00 PM All Break 3:00 - 4:30 PM All Continuation of all sessions 5:30 - 6:30 PM Miami Buffet Diner (Optional) 7:00 - 11:00 PM Menominee Hospitality & Demo area open 7:00 - 10:00 PM Miami Tucson Amateur Packet Radio (TAPR) Presents Special Interest Groups: - Packet BBS SYSOPs - VHF/UHF Network Building 7:00 - 10:00 PM Yakima American Digital Radio Society (ADRS)presents a technical presentation: "A Low Cost DSP Modem for HF Digital Experimentation" by Johan Forrer, KC7WW Sunday, August 21 TIME ROOM EVENT 8:30 - Noon Menominee Hospitality & Demo area open 10:00 - 11:00 Menominee Conference wrap-up and close. ---------------------------------------------------------------------------- 13th ARRL Digital Communications Conference Proceedings 1. A Proposal for a Standard Digital Radio Interface Jeffrey Austen, K9JA 2. Automatic Packet Reporting System (APRS) Bob Bruninga, WB4APR 3. Broadcast, UI and un-connected protocols-the future of Amateur Packet Radio? Paul Evans, W4/G4BKI 4. Packet, GPS, APRS and the Future Paul Evans, W4/G4BKI 5. Computer Networks in Africa: From Utopian Discourse to Working Reality Iain Cook 6. A Low Cost DSP Modem for HF Digital Experimentation Johan Forrer, KC7WW 7. G-TOR: The Protocol Mike Huslig, Phil Anderson, Karl Medcalf and Glenn Prescott 8. GMON-a G-TOR Monitoring Program for PC Compatibles Richard Huslig and Phil Anderson, W0XI 9. A Theoretical Evaluation of the G-TOR Hybrid ARQ Protocol Glenn E. Prescott, WB0SKX, And Phil Anderson, W0XI 10. On Fractal Compression of Images for Narrowband Channels and Storage W. Kinsner, VE4WK 11. Fast CELP Algorithm and Implementation for Speech Compression A. Langi, VE4ARM, W. Grieder, VE4WSG, and W. Kinsner, VE4WK 12. Wavelet Compression for Image Transmission Through Bandlimited Channels A. Langi, VE4ARM, and W. Kinsner, VE4WK 13. ROSE X.25 Packet Switch Status Update Thomas A. Moulton, W2VY 14. A Primer on Reliability as Applied to Amateur Radio Packet Networks T.C. McDermott, N5EG 15. FSK Modem with Scalable Baud Rate Wolf-Henning Rech, N1EOW, and Gunter Jost, KD7WJ 16. MacAPRS: Mac Automatic Packet Reporting System-A Macintosh Version of APRS Keith Sproul, WU2Z, and Mark Sproul, KB2ICI 17. Formation of the TAPR Bulletin Board System Special Interest Group David A. Wolf, WO5H 18. How Amateur Radio Operators Can Emulate an HF ALE Radio David R. Wortendyke, N0WGC 19. A Preview of HF Packet Radio Modem Protocol Performance Teresa Young, Stephen Rieman, David Wortendyke, N0WGC --------------------------------------------------------------------------- Rev. 7/12/94 [EOF] ----- End of forwarded message ----- ------------------------------ Date: Wed, 13 Jul 1994 10:57:18 -0500 From: David Rush Subject: Bridge vs. Repeater To: tcp-group@UCSD.EDU Steve said: >The argument that a router would be better than a repeater is off a >bit, as it assumes the user wants to route. Some may just want to chat, >or hook up with a (gulp) BBS... In this case the repeater attempts to >solve the hidden node problem, but so could DAMA, for a lot less. Well, isn't there a bit more than that? Even if two nearby users don't care about routing, a router can keep two local users from sucking up bandwidth... I'll share this with the group... I said: >> Yeah, presumably cross- or multi-banding would probably make the most >> sense (easiest). All of the stations in a "mutually hearable area" >> would share one freq on one band. The stations in a different >> "mutually hearable area" (on the other side of the mountaintop >> router) would share a different freq on a different band. Then Gerry said: >So, why not use a wide area machine on 2 in-band frequencies, using the >regen? It's a "repeater" to the FM guys, simple to maintain, simple to >build, simple to install. Find a good {tower/building top/mountain top} >and put it up to cover as much of the are as possible. If you THEN have >an area that's not adequately covered, put up another regen in that area >on the reverse channel, or route over to that remote area. Because traffic between two stations on the left side of the mountain would generate useless traffic (thru the regen) on the right side of the mountain. (Sucking up bandwidth.) A router could decide which packets need to cross over the mountain, but otherwise stay quiet. Assuming that nobody even cares about routing in this case, what I'm really proposing is a bridge (to use Ethernet terminology) between the two sides of the mountain, rather than bit regenerator. And when we say "bit regenerator", it's functionally equivalent to an Ethernet repeater, aren't we? David --------------------------------------------------------------- David Rush, SRI International, Leavenworth, Kansas 913-682-9101 rush@erg.sri.com, david@n0oxh.ampr.org ------------------------------ Date: Wed, 13 Jul 1994 17:47:06 +0100 From: "Brian A. Lantz" Subject: Managing MSS and Window; IP encapsulation To: TCP Group Mailing List On Wed, 13 Jul 1994, Phil Karn wrote: > Can people tell me whether the receive-side change has made it yet to the > NOS variants that people are using as wormhole gateways? Or do I need > to keep 94 on the transmit end a little longer to avoid compatibility > problems? > TNOS, based on an earlier version of JNOS, only checks for receiving 94. It's funny that this came up today, since I was looking at a couple of different IPIP listings (including xNOS) to see what differences there were, since I'm looking into figuring out the patches needed to do it under Linux. Phil's is the only one I KNOW about that checks also for a '4'. ----------------------------------------------------------- Brian A. Lantz/KO4KS brian@lantz.cftnet.com REAL PORTION of Microsoft Windows code: while (memory_available) { eat_major_portion_of_memory (no_real_reason); if (feel_like_it) make_user_THINK (this_is_an_OS); gates_bank_balance++; } ------------------------------ Date: Thu, 14 Jul 1994 02:32:33 -0700 From: Phil Karn Subject: Managing MSS and Window; IP encapsulation To: A.Cox@swansea.ac.uk IPNG is, in my opinion, years in the future. Beyond my current horizon, anyway. And even if it wasn't, it's still worth doing for IPv4. One situation in particular could really benefit: tunnel encapsulation. A maximum sized packet being encapsulated could easily generate two fragments, one maximum sized and the second very small. Path MTU discovery could help avoid this. What do you mean by MTU discovery breaking? I know that many routers don't yet indicate the interface MTU when they bounce a too-large packet with DF set. I plan to handle that by stepping through a table of common MTU values. My only concern about path MTU discovery is exactly how often I should try to increase the MSS to probe for a possible route change after it has been decreased. Given the relatively static routes on the net I would probably say "rarely", but I don't like hard-coded values in protocols that are supposed to be self-scaling. Phil ------------------------------ Date: Thu, 14 Jul 1994 10:50:44 +0200 (BST) From: A.Cox@swansea.ac.uk (Alan Cox) Subject: Managing MSS and Window; IP encapsulation To: karn@com.qualcomm (Phil Karn) > What do you mean by MTU discovery breaking? I know that many routers > don't yet indicate the interface MTU when they bounce a too-large > packet with DF set. I plan to handle that by stepping through a table > of common MTU values. A measurable number of low grade routers simply 'lose' oversized packets. I've had several network problems I have chased down to MTU discovery on SYS5.4 machines failing because routers on the way simply ate any oversized frames without sending back an ICMP or sending back an icmp with a hop count of 16 that never arrives back. I suppose the answer to this is 'tcp discovery off' as a KA9Q command 8). > My only concern about path MTU discovery is exactly how often I should > try to increase the MSS to probe for a possible route change after it > has been decreased. Given the relatively static routes on the net I > would probably say "rarely", but I don't like hard-coded values in > protocols that are supposed to be self-scaling. An off the cuff suggestion would be when you see a significant shift in round trip time for a measurable duration being one. Another clue would be the hop count on received tcp frames changing, and the third obvious one is if your local route table shifts. Alan ------------------------------ End of TCP-Group Digest V94 #148 ******************************